Thank you for watching, and I'll see you next time.
We'll be right back.
We'll be right back.
We'll be right back.
As you can see, this is the first presentation, and I'm going to present and discuss some issues for designing buffer overflow exploits, mainly focusing on small payloads.
My name is Anders Ingeborn. I'm from Sweden, and just before I begin, I'd like to give away some free stuff.
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My name is Anders Ingeborn. I'm from Sweden, and just before I begin, I'd like to give away some free stuff.
Okay, I better get home.
As you can see, I tend to lose them quite quickly.
Okay, anyway, why would anyone be interested in buffer overflows?
I can see two reasons.
These attacks are very effective.
They're very flexible and very useful.
You can run your own code on the target system.
You can run basically whatever you want if you manage to exploit an application.
If you exploit an application that uses an allowed protocol, it will go through a firewall,
let's say HTTP or FTP or something that's allowed to pass the firewalls and IDSs.
That's the first reason.
Effective and flexible attacks, really cool stuff.
Then the second reason why anyone would be interested in buffer overflows is that they
are very common.
I read this report.
It's two years old now, but from the Oregon Institute of Science and Technology, I think.
They stated that buffer overflow has been the single most common computer security flaw
or problem for 10 years.
That's another reason to be interested in this.
If you have any questions, please contact me to provide answers at aclu.com or aclu.org.
I'll see you next time.
Bye-bye.
Bye.
Bye.
Bye.
Bye.
Bye.
nodes, I think that you can add to the number of possible applications to exploit.
As a benefit, it turns out that these suggestions and these design issues that I present will
make it possible to evade some intrusion detection systems, both network-based and host-based.
And I'll get back to that later, of course. First, how many of you are perfectly sure
about buffer overflows, and how many need a little reminder? How many need a reminder?
Yeah, at least one. You won't get a t-shirt this time.
Okay, let's say an application does a string copy operation without a bounce check.
Then that will mean that the function will copy data from one method.
One place in memory until another, and go on until it reaches a null byte.
If it doesn't reach it, it will go on copying and overwrite memory, and write outside the
memory that has been reserved for that variable, which means that you will overwrite your stored
instruction pointer, and you may jump into your own code.
Excuse me?
Yes.
Speak louder.
Speak louder.
Speak louder.
Speak louder.
Speak louder.
There's no volume, but I...
Okay.
Okay, here's a picture of it. Let's say I do a function call, then you store your original
instruction pointer on the stack memory. You reserve space for some local variable,
and then you perform a string copy. Without a bounce check, you will overwrite the instruction
pointer, and then you may jump back into your own code, or jump wherever you want in memory.
So this is pretty cool.
But let's say some...
Some vulnerable server performs a bounce check. Let's say it receives data over a network
connection and implements some sort of bounce check on the receive call, but then not on
internal copy functions or such. Then we have a restriction. Then we have a bounce
check that we have to somewhat get around to exploit this application.
I see two possible ways of doing this. Either we can write a simple, small exploit code,
where the exploit itself is small enough to fit into this restricted memory and still
do what kind of exploit we want to do. It's a little naive, but it's okay, and that's
what we did in our last winter. Another approach which might be better is to change the design
concept somewhat and make a double injection, and that is basically what I'm going to present
here today.
But first, let's have a small look at the straightforward, simple, small exploits.
It will imply at least two functional requirements for the exploit itself. It has to be able
to listen for requests over a network and execute those at system commands. That's basically
what we want to do when we exploit an application. And we also have a requirement to keep the
number of bytes as low as possible.
Last time we did it, we came up with an example that was just above 250 bytes. We used two
libraries, Windows sockets and kernel 32. We used a datagram socket instead of a stream
socket because UDP don't need to do, because with UDP you don't need to do any listen
or accept calls, and you save a few bytes. And then we went into a loop doing receive
and executing with WinExec from kernel 32.
If you want to have a look at this one, you can download it from SecurityFocus. It's about
half year old.
Now, for the second approach that I think is much more cool is to change the design
concept and do a double injection. And of course, I will explain that on the next slide.
Besides changing the design concept, we can also try to use the existing network connection
and try to reuse the already loaded libraries to further minimize and optimize our code
to get even smaller.
So that's two parts, change the concept and optimize.
So what do I mean by double injection? Let's say you have a server process in the middle
that listens for connection over the network, and when it receives a request from a client,
it calls an internal parse and execute function to, yeah, well, to parse and execute. So,
it looks like this. And the server is running. Let's say we are at this place in the server
code, and some client over the network calls the server. Then when the server receives
the first call, the first command or request or whatever, the server will call the parse
and execute function and store the current instruction pointer onto the stack memory
on top of its stack frame.
Stack frame number one belongs to the server.
The server process and call jump into the instructions of the parse and execute function.
The parse and execute function will receive a stack frame of its own, which is being placed
above the service stack frame onto the stack memory. And then the parse and execute performs
a string copy call. So, let's say we have a restriction on the number of bytes for the
first call from the client to the server. But let's say we have no bounce check within
the parse and execute function.
That means the array of functions calls to string copy.
Then the first payload we send through the first call will overwrite down the second
stack frame and overwrite the instruction pointer.
.
Excuse me?
.
Yes. Yes. So, the stack grows upwards, and variables are written downwards on the stack.
.
.
On the next few couple of slides, I have written memory addresses to us so you can see them,
but not in this very fine animation.
The first time I made a PowerPoint animation.
Well, anyway, okay, the second part of the double injection is when the first payload
executes and listens for a second injection or a second call from the client, it reads
the second payload and stores it higher up on the stack where we have free memory, lower
address.
Then the first payload when it has received the entire second payload, it jumps up to
it and continues to execute the second payload.
We're still executing on the stack.
Then the second payload can perform the actual exploit and by that I mean open a shell and
or add an account or whatever that we want to do to exploit this host server.
The benefits of doing this is, of course, that we get lower memory requirements for
the first payload. And it's basically only the first payload
in this approach that is interesting, because if the first payload is small enough, then
the first stack frame, that one that belonged to the server, will be preserved.
And if it's preserved, then we might be able to do a clean return to the calling function.
And if we can do this clean return, the server function will not crash.
And if it doesn't crash, we'll get no log entry on the system.
And if we'll get no log entry, we will evade some host-based intrusion detection systems,
mainly those that just parse these log files.
Okay, part number two, or trick number two, is to use the existing connection.
And that means that we let the server open a new socket and receives the first payload.
And then we manage to get the first payload to receive the second payload over the same
session by using the same socket. Benefits of doing this is that we do not need
to set up any new files. We don't need to set up any new files.
We don't need to set up any new connection. And if we don't need to set up any new connection,
we will, or we might, evade some intrusion detection systems, some network-based intrusion
detection system that looks for TCP handshakes or that looks for unrecognized elite ports
over the network. But we're using the same still-allowed protocol,
the same still-allowed port number. It's the same session.
Okay.
Okay.
And that will make it harder for network-based intrusion detection to see it.
Of course, we will also get even lower memory requirements for the first payload, and that's
a benefit too.
Okay. I hope this sounds cool. But how can we do it? I have made a small proof-of-concept
implementation that I'm giving away after this speech or after DEF CON. I think I will
put it up on the post-DEF CON pages together with my slides if you want it, where I have
implemented a small vulnerable server that accepts connection, receives commands with
this restriction, calls this vulnerable parse and execute function, and is possible to exploit.
And also I will provide, of course, a remote client with these exploits. And they cannot
be used on anything but this particular server, of course.
Okay.
Okay.
So I'm a little surprised that you didn't ask this before I got to the slide. But isn't
it interesting how we will manage to use the existing connection?
I say we have to find the socket descriptor and use it. And how to find it is by finding
the accept call. The accept call can be found by disassembling the server and the main
one. And maybe look for an error message or something. And then set a break point at
that address in the code and debug the program. And then look where the return value from
the accept call is being stored in memory because the accept call returns the socket
descriptor for the session socket.
There's a plenty of disassemblers available on the internet. And that's just one example.
This one's free.
If you run a disassembler on the server that I'm providing, you will get this. And if
you look through the disassembled code, you will find an error message that is quite useful.
It shows us that the accept function is probably that one. And then we know that we can set
our break point at this address. Then we debug the program. And we get this. We see where
the session socket is.
The socket is being stored.
Okay, so we have found it. And then to use it, we need to know that the socket's position
within the stack frame does not change. While the stack frame itself might change. The stack
frame's position might change, that is, so if we now a fixed position within the stack
frame. So if we know a fixed position within the stack frame, we can then re-suce it. So,
calculate where the socket is being stored and reuse it. So this is second
animation and it shows what the first payload is basically doing. When the
first payload starts the base pointer has been overwritten and the stack
pointer points towards the end of the first payload. First I do is to change
the base pointer and move the stack pointer upwards against free
memory. Then I add some arguments for the receive function. I set a pointer to
the buffer where we want to store the second payload in free
memory and then the socket. Because I know that the distance from
the base pointer to the socket will always be the same and the base pointer
will be set during runtime. So I can always find the socket description
here.
So that's using the socket. To further minimize and optimize the code of the
first payload I suggest to use those functions that have already been loaded
by the server. And of course the server needs to use some functions from the
Windows socket library. I mean it receives the first
payload. And the addresses to this function are being stored at known places
within the instructions of the server process as long as it hasn't been
relocated. While the library may be stored wherever in memory. Not wherever
but at an unknown place. So this is what happens when the server calls a function
within the Windows socket library.
The server uses its jump table. And if we disassemble the server code one more time
we find this. This is the jump table. And by just reading the code or by debugging we can
deduce that these addresses correspond to these functions. So if we want to do a receive function
or if we want to call the receive function we can do it like this.
Are you following?
This is just a picture of the first payload in Memorand. As you can see the addresses
are printed to the left. And this is the code itself. As you can see I'll start by
subtracting at least at least as much
amount of memory from the stack pointer that I
need to store the second payload. Then I push the arguments to the receive
function onto the stack. The new stack frame. And then I basically call the
receive function through the jump table within the server.
and then I jump to the second payload you have any questions on this first
payload I have some pens anyway okay so what's to send the second time I mean
you can send whatever you can send your code of choice you do not need to to
feel any restrictions for the size of the code to send the second time you can
send code that opens a shell and performs or performs whatever action you
want to do to exploit this server and remember you may still use the same
socket you may still use the jump table for the functions that has already been
loaded as well as you might might try to load your own libraries and look up new
functions another important thing concerning the second payload is that we
do not need to XOR place
protect the second payload because it's being sent to the stack is being written
to the stack as raw data over a socket the first payload is written to the
stack by a string copy operation and as you probably know we cannot have any
nulls within that because then the string copy function will stop so we
need to XOR protect them but for the second payload we do not need to bother
to XOR protect the data the proof of concept implementation that I have made
it's it does not exploit this server in any particular way it just confirms its
success by sending a short message back to the client
ok so this isn't picture of what to say second payload does when the second
payload starts running
the base pointer still points to the base of the first payload and the stack
pointer points to the to the top of the second payload the instruction pointer is
of course at the top of the second payload because we have made a jump I
call the sync send function I add I push this the arguments for the send
function to the stack and I call the stack and I call the send function sorry
and then I'm finishing up
thank you
when I'm finishing up I want to do a clean return because as you remember if
I do a clean return I won't get an area entry to the system log and I will I
can use that to possibly evade and host based intrusion detection system so to
To be able to do a clean return, I need to reset the base pointer and the stack pointer
to their originally intended positions with respect to the first stack frame, the stack
frame of the calling function, and I need to reset the instruction pointer to point
back into the service instruction codes. Of course, if the parse and execute function
is supposed to return anything special, I have to set that up as well.
Since I haven't changed the base pointer throughout the execution of the second payload, and I
remember that the base pointer did point to the stack pointer before I started, I can
simply set them back. And since I know that the stack frame of the calling function is
always
of the same size, I can calculate what to set the base pointer to.
I mean, all of these stack frames, their position in memory may change, and I do not know that
until runtime. But what I do know is that the size of the stack frame is always the same,
and thereby I can calculate what to set the base pointer to. And then I can do a clean return.
Back to the server. Back to the service or original instructions. With both the stack pointer and the base
pointer reset to its original values, and the stack frame of the calling function not disrupted in any
way. Do you have any questions? Yeah. You want the pen before? Nah, sorry.
Let's say you just have a... Okay, the question was, can you do this without having the source code for the server?
And the answer is, yes, if you manage to read only the disassembly. If you have the binary, you can still disassemble it.
Okay, if it's only a remote situation.
No, you need to disassemble the server. But since you're only supposed to evaluate your own programs,
you will probably have access to the binary, right? You want a black one or a purple one?
Okay. Cool. Any more questions? Yeah.
The first payload overwrites the original return address. Yes. Yeah. Yeah. Okay, how do I know what to set the instruction
pointer to do a clean return?
I get it from the disassembly code, and it will be the same... Excuse me?
Excuse me?
I don't know if I got it right, but...
Let's try to answer something and see if it fits.
When I disassemble the server, I can find the address for the call, and I know that
the return, supposed return address is the address next, the next address.
And as long as the server hasn't been relocated in memory, this address will be the same because
as long as the server hasn't been relocated through anything, its base address will always
be this 0040, 0000.
You can set that when you compile your binary.
And you will see it when you disassemble your binary, too.
You want a purple or a black one?
You don't want any.
Okay.
.
Yes, Steven.
.
.
.
.
.
cannot overwrite the it cannot be allowed to disrupt the first stack frame
and that that might be true that might be possible or that might not be
possible there are some other conditions that has to be met too but I think the
concept the idea it will be able to do on other servers as well yes you
okay the question was how effective is a non-executable stack frame I would say
it's quite effective but let's say one possible way to get around it might be
to to jump to maybe an argument that is being stored on the heap or something
instead
basically I
basically I
basically I'm kind of amazed that stack frames aren't being protected from
execution you want the last time sorry okay so I ran out of pants or ran out of
free stuff and I'm basically running out of slides too so I'm going to finish off
and
and so this is just the payloads in memory and as you can see I just send a
simple stupid message back from the second payload to the calling client this
is the code for the second payload as you can see it's basically just a number
of push operations to push the arguments to the send function and then call the
same some function through the jump table of the server and then reset the
the stack pointers and return so the return address in this example is hard coded into the second payload because on this second last line
right
to summarize this I've 자막 고민 Finan party
discussed a double injection and by a
double injection I mean that we have we
offend us that first page wasn't one
payload that uploads a second payload
sollten payload and then jumps to the
second payload and that the second
payload
execute the actual exploit like the shell or something I've suggested to try
to use an existing network connection by finding and supplying an existing socket
descriptor to the receive and send functions and I have also suggested to
try to use the existing functions the preloaded ones through the jump table of
the original program by doing this it might be possible to evade a network
based intrusion detection system there are no elite ports and no TCP handshakes
since we are sorry using the existing network connections there are not as
long as for the first payload there are no large amount of amounts of data being
sent and it this by doing this we force and network-based intrusion detection
system into interpreting the
application system and the process to perform the network based intrusion detection system into interpreting the actual
application protocol to see and detect the changes of my payloads from an
original yeah application protocol and that into interpretation will probably
it will definitely increase the complexity of the ideas and it will
probably decrease the capacity and slow down analysis have you read through
Caesars ASCII encoding paper that can also be used as a counter if if
application protocol interpretation by the network-based intrusion detection
system is a countermeasure against this attack Caesars ASCII encoding can be
seen as a counter counter measure so you can continue this by not setting up any
new connections and by returning cleanly without the crash there will be no log
error
entry and that will force and host based intrusion detection system to kind of
get some strange behavior awareness because the server won't function
properly but it won't crash either and true to be able to recognize the
difference between those two you need well some kind of abnormal behavior
detection and that will add complexity to
almost finished I really recommend you to read this the first one is a chapter
in the book called hack proofing your network by Greg Haglund it's really good
and the second paper I really recommend you to read is about windows buffer
overflows from frac by Barnaby Jack also known as the dark spirit is any of you
guys here
no
I give you credit anyway if you have any questions about this if you want more
information if you want to see a demonstration if you want to have a copy
of the code or the slides you can probably get them from the post defcon
pages or you can try to catch me here during the day I will be here all day
and all night probably and I'll leave back home for Sweden tomorrow morning or
you can also drop me an email at this email address any last question
yeah
with TCP and UDP but I think the concept is possible for
yeah
yeah
okay thank you very much for attending and please stay for the Cisco routers as
well thank you
